Field of the Invention
Field Programmable Gate Arrays (FPGAs) are electronic integrated circuits where the digital logic functions of the chip are determined by configuration data which is loaded into them. There are two predominant types of FPGAs today: those where the configuration data is held inside the device in volatile memory such as SRAM cells, and those where the configuration data is held in non-volatile memory such as flash memory cells. In the FPGAs using non-volatile configuration memory, the configuration data, often referred to as a “bitstream”, needs only be loaded once, usually during the circuit board manufacturing step soon after the FPGAs are soldered to the board, but it is also possible to program them in sockets before board assembly. Depending on the type of non-volatile memory used (e.g., anti-fuse vs. flash) it may be possible to optionally overwrite the design during development, manufacturing or later, in fielded systems. In FPGAs, using volatile configuration memory the data needs to be loaded each time power is removed and reapplied, therefore in SRAM FPGAs this configuration process must be performed repeatedly in fielded devices, i.e., at each power-up event.
Description of Related Art
The configuration data is most often regarded as proprietary intellectual property (IP). In order to protect the confidentiality of the IP and to ensure that only authentic bitstreams are loaded into devices, most higher-end FPGAs today include the ability to decrypt the bitstream upon loading, in which case the electronic design automation (EDA) tools that create the bitstream will prepare the bitstream in encrypted form in preparation for later decryption inside the device. Typically, a symmetric encryption scheme, for example, based on the Advanced Encryption Standard (AES) symmetric block cipher is used. In such symmetric schemes, the key used for encryption of the bitstream by the EDA tool is the same as the key used for decryption within the FPGA. The FPGA is loaded with this key (or its precursors) prior to loading the bitstream. It is common practice to load the same key into all the FPGAs used in a particular project where the desired as-configured FPGA functionality is the same, thus facilitating the use of the exact same encrypted bitstream for all the FPGAs in this group. In the prior art, using a different key in every FPGA would require encrypting the configuration bitstream, which is a relatively large amount of data, unique for each FPGA in the project (which could be a large number of FPGAs). This is generally considered to be too inefficient and costly in terms of compute time and storage space to be practical.
Encryption of the bitstream is an important step in protecting the IP it embodies. Creating working FPGA configuration files can be expensive in terms of engineering time, and can also include other valuable intellectual property of the IP owner such as trade secrets or even information of a national security interest. So, protecting the confidentiality of the IP is an important end in itself. Another reason to protect the confidentiality (and authenticity) of the configuration bitstream is that, being digital data, it is easily copied. Without the protection offered by cryptographic methods, it would be too easy for anyone to monitor the bitstream during loading and then make copies which are then loaded into additional FPGAs to produce unauthorized clones. When this is done by an unethical agent of the IP owner, such as his contract manufacturer, that is cloning not only the FPGA but also the entire board or system in which it is used, this is commonly called “overbuilding.” Making cloned copies of configured FPGAs does not necessarily require reverse engineering; it merely requires access to either the unencrypted configuration data (in which case it can be programmed directly into additional devices in plaintext, or encrypted under a new key and loaded), or the original key used by the legitimate devices to decrypt and authenticate incoming configuration data (in which case the existing encrypted file can be used to program additional devices after first loading the original key).
Positive control of the number of FPGAs that can be successfully configured with the IP owner's design can be used to effectively prevent overbuilding, since if the FPGAs cannot be cloned easily it is much more difficult to clone the entire system. In the prior art, overbuilding protection has been accomplished by carefully controlling the number of FPGAs with the (typically project-wide) decryption/authentication key loaded. Since only the FPGAs with the correct key(s) will successfully load the properly encrypted bitstream, the number of working systems that can be manufactured is also indirectly controlled. Yet another reason to keep the configuration bitstream confidential and to authenticate bitstreams that are accepted by the FPGAs is that if the design is reverse engineered from the bitstream there is a threat of it being modified in a malicious way, such as with the insertion of a Trojan Horse.
The cryptographic key needs to be stored in non-volatile memory, even in SRAM-based FPGAs. In SRAM FPGAs, the key must be persistent because it is required for decrypting the bitstream upon each power-up cycle. There are two common ways to make the key persistent in SRAM FPGAs: either the SRAM FPGA is equipped with enough non-volatile memory (e.g., anti-fuse cells) in order to hold the key, or a small amount of volatile memory is kept powered-on with the aid of a battery so the key is not lost when the rest of the device is powered-down. In flash-based FPGAs, since the configuration itself is persistent, the key only needs to be persistent if the configuration of the FPGA needs to be changed at a later date, and encryption protection is desired. For example, this could be for an update performed in a less-trusted location, such as in a fielded system, where the threat of monitoring attacks is greater.
Many FPGAs are loaded by the original component manufacturer with a unique-per-device public value, such as a serial number, though different names may be used for it. In some prior art flash-based FPGAs, a shared manufacturer secret key may be pre-loaded in a multitude of devices. However, in no prior art FPGAs did the manufacturer load a unique-per-device secret (or private) key intended to be used for protecting user configuration data with encryption and/or authentication. One ostensible reason for this has been the impracticality of encrypting a separate bitstream configuration file for each device due to the large amount of configuration data.